Are co-routine lambdas safe now? I recall an announcement around this but haven't dug in enough yet.

this is the current state of play https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines/avoid-capturing-lambda-coroutines.html

tl;dr it's ok if you use explicit this param (or don't capture anything)

The commit title for this says that this leads to a "retry crash". How does this lead to a crash exactly? I suspect that it leads to an infinite or at least slow retry chain inside sequenced_write.

I think this new behaviour is incompatible, because we'd also start returning [list-of-all-soft-deleted-subvers] when soft-deleting a subject that is already soft-deleted (regardless if there's a race or not) whereas we are supposed to throw a 404 in that case as far as I can tell.

In the race scenario you describe, I think we're still supposed to return a 404, and the bug is perhaps to do with the logic of sequenced_write. Maybe we should only retry on write_collision errors inside sequenced_write and propagate all other errors immediately.

Am I missing something here?

This is what I was using for testing the behaviour under the scenario you describe where we're soft deleting a subject with all-soft-deleted subject versions:

  # Adjust to taste
  SR=http://localhost:8081
  SUBJECT=test-subject-value
  CT='Content-Type: application/vnd.schemaregistry.v1+json'

  # 1. Register schema v1 (Avro record with one field)
  curl -sS -X POST "$SR/subjects/$SUBJECT/versions" \
    -H "$CT" \
    -d '{"schema":"{\"type\":\"record\",\"name\":\"Foo\",\"fields\":[{\"name\":\"a\",\"type\":\"string\"}]}"}'
  echo

  # 2. Register schema v2 (add a field — backwards-compatible default added)
  curl -sS -X POST "$SR/subjects/$SUBJECT/versions" \
    -H "$CT" \
    -d '{"schema":"{\"type\":\"record\",\"name\":\"Foo\",\"fields\":[{\"name\":\"a\",\"type\":\"string\"},{\"name\":\"b\",\"type\":\"int\",\"default\":0}]}"}'
  echo

  # Sanity check — should list [1, 2]
  curl -sS "$SR/subjects/$SUBJECT/versions"; echo

  # 3. Soft-delete version 1
  curl -sS -X DELETE "$SR/subjects/$SUBJECT/versions/1"; echo

  # 4. Soft-delete version 2
  curl -sS -X DELETE "$SR/subjects/$SUBJECT/versions/2"; echo

  # Live versions list — expect 404 / empty (all soft-deleted)
  curl -sS -i "$SR/subjects/$SUBJECT/versions"; echo

  # Same list including soft-deleted — should still show [1, 2]
  curl -sS "$SR/subjects/$SUBJECT/versions?deleted=true"; echo

  # 5. The interesting call: soft-delete the subject when all versions
  #    are already soft-deleted. Use -i so you see the status code.
  curl -sS -i -X DELETE "$SR/subjects/$SUBJECT"; echo

Maybe we should only retry on write_collision errors inside sequenced_write

good idea

Am I missing something?

Don't think so. Added this after some test failure early on in refactoring, and I'm still not sure there was any faulty behavior at all. I kept it in on the off chance you or someone else would say "oh yes, of course that's a bug", but I think I'll just remove it. We can address in a follow up if it seems like there's a real improvement to be made.